Software application development is a conceptually simple process. As shown in FIG. 2, a programmer creates the software (210), then tests it (220) to see whether it operates as intended. If the software does not operate as intended (230), the programmer alters the software (240) and tests it again (220). Theoretically, the test/edit cycle will eventually produce the desired application.
Of course, as with many activities, the devil is in the details. For example, creating the software (210) may entail writing source code (212), compiling and linking the source code (215) to prepare binary instructions suitable for execution on a programmable processor, and installing the program on a target machine (218) if the software development occurs on a different system. Testing the software (220) may entail executing the software and examining the results it produces (223), as well as observing the program's execution with a development tool called a debugger (227). The “edit” portion of the cycle (240) may be similar to the “create” portion (210): the programmer may edit the source code (242), compile and link the edited source (245), and re-install the compiled program on a target system (248).
Certain programming styles and environments tend to have a large number of process-related details that can trip up an unwary programmer and delay software development. These details have little to do with the software application itself, but instead are a consequence of the type of application and/or the development environment. For example, applications that use shared or loadable modules, and applications that are written in a cross-development environment (where source code and binaries are prepared on one system, but intended to be executed on a different system), often include several administrative steps in the test/edit cycle which, if not performed correctly, can result in confusing application behavior. Automatic tools to detect errors in these administrative steps can help prevent lost development time.